MULTI-NETWORK HANDLING MANAGEMENT METHOD

专利摘要:
In the context of roaming management by multi-network transfer, a communication system comprises a first network of LPWAN type from a first operator and a second network of LPWAN type from a second operator. The first network includes subnets (100, 101, 102) implementing separate respective transport protocols. The subnetworks include at least one convergence node and communication nodes integrating collection gateways. The first network includes servers (131, 134) interconnected to a server (140) of the second network interfacing an application server (150) and an authentication server (160). Upward frames of application data are transported from a terminal device (110) of the second operator to the application server (150) by successive relays of the servers. But when the terminal device (110) of the second operator requests to join the communication system to benefit from the services of the application server (150), the collection gateways communicate directly with the authentication server (160) by short-circuiting the others servers as well as the convergence nodes to which said collection gateways are respectively attached.
公开号:FR3086482A1
申请号:FR1871087
申请日:2018-09-25
公开日:2020-03-27
发明作者:Henri TEBOULLE；Marc Le Gourrierec；Franck Harnay；Guillaume Moreau
申请人:Sagemcom Energy and Telecom SAS；
IPC主号:

专利说明:

Description
Title of the invention: MULTI-NETWORK roaming management method
Technical Field [0001] The present invention relates to a method of managing roaming by multi-network transfer (“handover roaming” in the context of a communication system comprising a first network and a second network, each based on a communication technology of the LPWAN type (“Low-Power Wide-Area Network” in English) and in which the first network comprises sub-networks implementing distinct transport protocols.
PRIOR ART [0002] The Internet of Things is emerging. The Internet of Things represents the extension of the Internet to things and places in the physical world. While the Internet does not usually extend beyond the electronic world, the Internet of Things represents the exchange of information and data from devices in the real world to the Internet, such as for example collection of statements of electrical consumption or water consumption. The Internet of Things is considered the third evolution of the Internet, called Web 3.0. The Internet of Things is partly responsible for the current increase in the volume of data to be transmitted and stored, and is therefore at the origin of what is called "Big Data". The Internet of Things is universal in designating the communication of objects for various uses, for example in the industrial, agro-food, e-health or home automation fields.
To allow communicating objects, also called terminal devices, to communicate within the framework of the Internet of Objects, communication systems are set up thanks to a set of collection gateways (“gathering gateways” in English ) which are located on geographically high points and which are deployed by an operator. Except for maintenance operations, these collection gateways are typically fixed and permanent, and communicate with the terminal devices by radio. We can for example cite on this model the SigLox (registered trademark) or ThingPark (registered trademark) networks. These collection gateways communicate with the terminal devices by means of medium or long range radio communications using an LPWAN type communication technology, such as, for example, LoRaWAN (“Long Range Wide-Area Network”) technology, also known as short for LoRa (Long Range) from the name of the alliance promoting LoRaWAN technology. These collection gateways thus serve as relays between the terminal devices and a core network, typically consisting of a set of servers, of the communication system.
Terminal devices are often battery powered devices and are therefore expected to go to sleep as much as possible in order to improve their energy autonomy. To this end, these terminal devices apply, in their indirect communications with the core network (via one or more collection gateways), a communication mechanism known as "Class A" in the LoRaWAN protocol. This mechanism consists in defining, deterministically for a terminal device considered and the collection gateway which acts as a relay for the core network, one or more reception windows during which the terminal device considered listens to the communication medium where the downlink communications must be performed. One or more reception windows begin at the end of a period of predefined duration after an instant of transmission of ascending frame by the terminal device in question and also have a predefined duration. Two reception windows are thus defined in the case of the LoRaWAN protocol defined in version 1.1 of the specifications of October 11, 2017. A downlink frame which must be addressed to said terminal device is then performed in one or the other (if applicable) ) of said reception windows, in particular for acknowledging said ascending frame. It is indeed typically necessary for the terminal device in question to know that the core network has effectively received the ascending frame transmitted by said terminal device. This reception window approach starting at deterministic moments for the terminal device in question and the collection gateway which acts as a relay for the server allows said terminal device to go to sleep in the meantime and thus preserve its energy autonomy. Note that there is an evolution of this reception window mechanism, known as "Class B" in the LoRaWAN protocol, which defines reception windows notified in tags transmitted by the collection gateways. And for terminal devices that have more energy autonomy, a third mechanism is available, known as "Class C" in the LoRaWAN protocol, in which the terminal devices are supposed to constantly listen to the communication medium.
Note that we speak of a frame or upward communication when a frame or a communication goes up from a terminal device to the core network, and that we speak of a frame or downward communication in the opposite direction.
However, it is not certain that the round trip time between the collection gateways and the core network systematically makes it possible to meet expected reception deadlines, more particularly for “Class” terminal devices.
A ”where top-down communications opportunities are few. This is particularly the case when the terminal device joins the communication system, especially in situations of roaming by multi-network transfer. This situation is illustrated by the exchange of messages shown diagrammatically in FIG. 2 on the basis of a system architecture shown diagrammatically in FIG. 1 in which two networks of two operators interact to form the communication system. It is to be distinguished from passive roaming situations (“passive roaming” in English) where the MAC layer (“Medium Access Control” in English) is managed remotely by the operator's core network with which a service subscription has been performed. A main advantage of roaming by multi-network transfer is that the MAC layer control plan is managed by the host core network, which allows better matching of the settings (carrier frequencies, spreading factor ...) terminal devices vis-à-vis the effective conditions of communication with the host core network which provides the relay with the core network of the operator with which the service subscription has been made. Compared to passive roaming, this improves the ability to ensure continuity of services under very good conditions.
[0007] FIG. 1 thus schematically illustrates an Internet of Things communication system suitable for roaming by multi-network transfer. The communication system comprises a first LPWAN type network of a first operator interconnected to a second LPWAN type network of a second operator. The first network includes at least one collection gateway 120, 121, 122 (denoted GW, for “GateWay” in English, in Figs.). The collection gateways 120, 121, 122 have respective communication links with a core network of the first network of the first operator. Three collection gateways of the first network are shown in FIG. 1, but the communication system may include a different amount of collection gateways. The second network also includes such collection gateways, which are however not shown for the sake of simplification.
In the communication system, messages must be sent in the form of frames from a set of terminal devices (noted ED, for "End Device" in English, in Figs.) To the core network. Although the communication system comprises two networks, and therefore two core networks, the latter are perceived as a single core network by the terminal devices. In other words, roaming by multi-network transfer is transparent to terminal devices. A single terminal device 110 is shown in FIG. 1 for the sake of simplification, but the communication system typically includes a large quantity of terminal devices.
Any core network has a role in monitoring and collecting information available from terminal devices, and the collection gateways 120, 121, 122 have a relay role between the terminal devices and the core network. To enable this relay role to be fulfilled, each collection gateway 120, 121, 122 has at least one radio interface allowing said collection gateway to communicate with at least one terminal device by relying on a communication medium without -wire, and preferably according to a communication technology of the LPWAN type. Said radio interface is for example of the LoRa type, thus making it possible to implement, within the communication system, a data transmission protocol of the LoRaWAN type. Said radio interface is such that a terminal device can be within radio range of a plurality of collection gateways, depending on the geographical position of said terminal device with respect to the collection gateways 120, 121, 122 and radio conditions in the environment said terminal device and collection gateways 120, 121, 122. This is the case, for example, of the terminal device 110 on the Lig. 1, which is within radio range of the collection gateways 120, 121 and 122. In addition, each collection gateway 120, 121, 122 has at least one other interface allowing said collection gateway to communicate with the core network. For example, this other interface is a wired interface for communicating with the core network via the Internet or a radio interface of the GPRS (General Packet Radio Service) type.
The core network of the first operator is suitable for roaming by multi-network transfer in collaboration with the core network of the second network. Thus, the core network of the first operator comprises a first LNS server (“Lorward Network Server” in English) 130 in charge of managing the collection gateways 120, 121, 122 on behalf of said core network and in particular ensuring the deduplication of the ascending frames received from terminal devices via said collection gateways 120, 121, 122. The core network of the first operator also comprises a second SNS server (“Serving Network Server” 134) coupled to the first LNS server 130. The second server SNS 134 is in charge of controlling the MAC layer for the terminal devices communicating via the collection gateways 120, 121, 122 which are managed by the first LNS server 130. The first LNS 130 server and the second SNS 134 server can be implemented in the same material entity.
The core network of the second operator includes a third HNS server (“Home Network Server” 140), which is the server which coordinates the core network of the second operator. This third HNS server 140 is the equivalent in the second network of the second SNS server 134 in the first network. Moreover, the second network typically also includes a server equivalent to the LNS 130 server, coupled to the third HNS 140 server, and which manages the collection gateways of the second network.
The core network of the second operator also includes a fourth AS 150 server, which implements an application with which the terminal device 110 communicates,
i.e., exchange of application data, as part of the service subscription. The core network of the second operator can comprise a plurality of such fourth AS 150 servers. Finally, the core network of the second operator also comprises a fifth JS 160 server, responsible for managing subscriptions of the terminal devices in order to verify the subscription necessary to enable them to benefit from the services of the fourth server AS 150 when said terminal devices seek to join the communication system.
The fourth AS 150 server and the fifth JS 160 server are declared to the third HNS server 140, and are thus connected to the third HNS server 140. The second SNS server 134 communicates with the third HNS server 140 which serves as a relay with the fourth AS 150 server and the fifth JS 160 server in the context of communications with the terminal device 110. In other words, the third HNS server 140 is in charge of interfacing the fourth AS 150 server and the fifth JS 160 server with the first network and more particularly with the second SNS 134 server.
However, there are situations where the second SNS server 134 of the first operator communicates directly with the fifth JS server 160 of the second operator, particularly when the second SNS server 134 does not yet know the identity of the third HNS server 140 at the time. where the terminal device 110 roams the network via the first ENS server 130. In this case, the second SNS server 134 uses an identifier, called JoinEUI in the LoRaWAN 1.1 specifications, which uniquely identifies the fifth JS 160 server and that the terminal device 110 includes in a message that said terminal device 110 transmits to join the network. The second SNS server 134 then contacts a sixth DNS server ("Domain Name Server" in English) in charge of performing domain name resolutions. This sixth DNS server (not shown) then supplies the second SNS server 134 with an address for contacting the fifth JS server 160 using the unique identifier in question. The second SNS server 134 then supplies the fifth JS server 160 with another identifier, called DevEUI in the LoRaWAN 1.1 specifications, which uniquely identifies the terminal device 110 so that the fifth JS server 160 therefore supplies the identity of the third HNS server 140 in return, because the same JS 160 server can interact with at least one other server equivalent to the third HNS server 140.
Note that other communication links (not shown, for the sake of simplification) between the servers may exist within each of the first and second networks, in particular between the fourth AS 150 server and the fifth JS 150 server.
When the terminal device 110 joins the communication system by roaming by multi-network transfer, exchanges of messages are carried out, as illustrated diagrammatically in FIG. 2.
In a step 201, the terminal device 110 transmits a JOIN-REQ message via its radio interface. This message is called Join-request in the LoRaWAN 1.1 specifications. As indicated previously, this JOIN-REQ message includes a unique identifier of the terminal device 110 and a unique identifier of the fifth JS server 160. This JOIN-REQ message is received by at least one collection gateway 120, 121, 122. Let us consider that this JOIN-REQ message has been received by the collection gateway 121. The latter then relays, in a step 202, the JOIN-REQ message to the first FNS server 130 to which said collection gateway 121 is attached. The first FNS server 130 then relays the JOIN-REQ message to the second SNS server 134 in a step 203. The second SNS server 134 detects that the JOIN-REQ message concerns a terminal device while roaming. The second SNS server 134 then relays the JOIN-REQ message to the third HNS server 140, in the form of an HRS-REQ message, in a step 204. This message is called HRStartReq in the LoRaWAN Backend Interfaces 1.0 specifications, which deal with roaming in the context of LoRaWAN 1.1 specifications. This HRS-REQ message typically contains additional MAC layer management information by the second SNS server 134. Then, in a step 205, the third HNS server 140 relays the JOIN-REQ message, in the form of a JREQ message, to the fifth JS 160 server. This message is called JoinReq in the LoRaWAN 1.1 specifications. This JREQ message typically contains part of the additional MAC layer management information contained in the HRS-REQ message. The fifth JS server 160 then performs the authentication of the terminal device 110 and in the event of successful authentication, generates the security keys necessary for the terminal device 110 to communicate in the communication system and benefit from the services of the fourth server AS 150.
Then, a return is provided to the terminal device 110 while roaming. To do this, the fifth JS server 160 transmits to the third HNS server 140, in a step 206, a JANS message in response to the JREQ message. This message is called JoinAns in the LoRaWAN 1.1 specification. The JANS message includes a JOIN-ACC message to be relayed to the terminal device 110, and in the case where the terminal device 110 is effectively authenticated by the fifth JS 160 server, the security keys making it possible to ensure secure exchanges with the terminal device 110, including, in encrypted form by a key known to the terminal device 110, the security key to be used to communicate with the fourth AS 150 server. The JOIN-ACC message is called Join-accept in the LoRaWAN 1.1 specifications. The JANS message repeats the security keys allowing the terminal device 110 to communicate in the communication system, so that the communications of the terminal device 110 can be managed by the core network of the first operator (with the exception therefore of the key of security allowing the terminal device 110 to communicate with the fourth server AS 150). In a step 207, the third HNS server 140 transmits to the second SNS server 134 an HRS-ANS message in response to the HRS-REQ message, which includes the content of the JANS message as well as service profile information relating to the terminal device 110 in roaming. This message is called HRStartAns in the LoRaWAN Backend Interfaces 1.0 specification. In a step 208, the second SNS server 134 relays to the first FNS server 130 the JOINACC message created by the fifth JS server 160. Then, in a step 209, the first FNS server 130 selects the collection gateway responsible for relaying the message JOIN-ACC to terminal device 110 and forwards it to said JOIN-ACC message. Let us consider that the first FNS server 130 selects for this purpose the collection gateway 121. Then, in a step 210, the collection gateway 121 relays by radio said JOIN-ACC message for the attention of the terminal device 110.
From the above, it appears that the management of roaming by multi-network transfer involves numerous message relays, in particular between the different servers involved. These relays imply execution latencies which are added to significant processing latencies on the part of the servers, in particular with regard to the fifth JS 160 server. These message relays are therefore sometimes hardly compatible with latency deadlines to be observed, particularly in the case of the aforementioned reception windows, which means that the terminal devices may have to face great difficulties in joining the network, since they do not receive a response from the core network over time outsourced.
It is desirable to overcome these drawbacks of the state of the art. It is in particular desirable to increase the chances for the terminal devices to successfully join the network in the event of roaming by multi-network transfer, more particularly in the case where subnetworks implementing separate transport protocols are used to interconnect the end devices with the core network. Indeed, the use of subnetworks implementing separate transport protocols leads to differences in propagation latency which amplify the above-mentioned difficulties. It is also desirable to increase the chances for terminal devices that communications take place within a given timeframe in the context of the use of these subnets implementing separate transport protocols. It is also desirable to be able to rely on existing message formats in the LoRaWAN 1.1 specifications.
Disclosure of the invention To this end, a method of managing roaming by multi-network transfer is proposed in a communication system comprising a first network of LPWAN type from a first operator and a second network of LPWAN type d 'a second operator. The first network comprises: subnetworks each comprising at least one convergence node and communication nodes integrating collection gateways, the subnetworks implementing separate respective transport protocols; a first server, for each subnetwork, responsible for managing said collection gateways included in said subnet, each collection gateway communicating via a single convergence node associated with a single first associated server; and a second server, coupled to the very first server, responsible for controlling the MAC layer for terminal devices communicating via said collection gateways of the first network. The second network includes: a third server in charge of interfacing a fourth server and a fifth server with the second server of the first network; the fourth server, which implements an application with which at least one terminal device of the second operator exchanges application data within the framework of a service subscription defined with the second operator; and the fifth server, responsible for authenticating any terminal device seeking to join the communication system to benefit from the services of the fourth server. The method is such that the communication system transports ascending frames including application data from said at least one terminal device from the second operator to the fourth server by successive relays of a said first server, the second server and the third server when said at least one terminal device of the second operator is authenticated and in addition that said ascending frames are received by at least one collection gateway of the first network. The method is further such that each collection gateway of at least one subnet of the first network, which has detected a terminal device of the second operator requesting to join the communication system to benefit from the services of the fourth server, communicates with the fifth server for authenticating said terminal device of the second operator detected, by shorting the first server associated with said collection gateway, the second server and the third server by means of a communication interface also bypassing the convergence node associated with said collection gateway. Thus, the chances for the terminal devices of the second operator to successfully join the communication system despite the presence of various subnets implementing distinct transport protocols and therefore causing various propagation latencies in the case of roaming by multi-handover. networks are increased by significantly reducing latency by short-circuiting the first, second and third servers as well as the convergence node associated with the collection gateway concerned.
According to a particular embodiment, the first network having a range of addresses for all the terminal devices accessing the communication system via the collection gateways of the first network, the fifth server manages a predetermined subset of addresses of the address range of the first network and assigns an address from said predetermined subset of addresses to any terminal device of the second operator which is roaming by multi-network transfer via the first network and which is authenticated by the fifth server . Thus, the addressing of the terminal devices in the first network remains consistent although the first, second and third servers are short-circuited to authenticate the terminal devices of the second operator.
According to a particular embodiment, the communications with each authenticated terminal device of the second operator being encrypted, the fifth server provides the security keys necessary for said encrypted communications, and when a collection gateway of the first network receives a message from the fifth server indicating that a terminal device of the second operator has been successfully authenticated and including said security keys, said collection gateway of the first network relays the security keys to the first server associated with said collection gateway. Thus, the encryption and decryption of communications can be entrusted to another entity than the collection gateway of the first network to which the fifth server has responded.
According to a particular embodiment, the first server relays the security keys to the second server. Thus, the encryption and decryption of communications can be implemented at the second server although the first, second and third servers are short-circuited to authenticate said terminal device of the second operator. In addition, the second server can entrust the encryption and decryption of communications to another entity of another subnet of the first network through another first server.
According to a particular embodiment, to request to join the communication system to benefit from the services of the fourth server, each terminal device of the second operator sends a message including an identifier which uniquely identifies the fifth server, and each gateway of collection of the first network receiving said message determines to which address to contact the fifth server thanks to an association previously stored in memory between said identifier and the address to contact the fifth server. Thus, each collection gateway in the first network can easily determine that the fifth server should be contacted directly and how to contact the fifth server.
According to a particular embodiment, on configuration of each collection gateway of the first network with the identifier which uniquely identifies the fifth server, said collection gateway of the first network requests a sixth server, in charge of perform domain name resolutions, provide the address for contacting the fifth server using said identifier that uniquely identifies the fifth server. Thus, each collection gateway of the first network anticipated the need to contact the fifth server to manage the terminal devices of the second operator while roaming by multi-network transfer, which reduces processing latency by the time a terminal device of the second operator wishes to join the communication system by roaming by multi-network transfer.
According to a particular embodiment, on configuration of each first server with the identifier which uniquely identifies the fifth server, each first server requests a sixth server, responsible for carrying out domain name resolutions, providing the address for contacting the fifth server using said identifier which uniquely identifies the fifth server, and each first server propagates an association of said identifier and said address to each collection gateway which is associated with said first server. Thus, the procedure to initialize the collection gateways of the first network within the framework of roaming by multi-network transfer is simple and effective.
According to a particular embodiment, when the fifth server receives several copies of the same message which emanates from a terminal device of the second operator and which requests to join the communication system, the fifth server performs a data deduplication and responds to the first sequential copy of said message. Thus, the management of parallel uploads of copies of messages by different collection gateways of the first network is simple although the first, second and third servers are short-circuited to authenticate said terminal device of the second operator.
According to a particular embodiment, when a collection gateway of the first network receives a message from the fifth server indicating that a terminal device of the second operator has been successfully authenticated, said collection gateway activates a delegation and notifies in Consequently, the first server with which said collection gateway is associated, the delegation comprising the following steps: assigning a buffer to said terminal device of the second operator and storing therein useful data subsequently received asynchronously via said first server to the attention of said terminal device. the second operator; acknowledge any ascending frame subsequently received from said terminal device from the second operator by constructing and transmitting, on behalf of the second server, descending frames including respective acknowledgments of said ascending frames and including, where appropriate, useful data stored in the buffer assigned to said terminal device of the second operator; and relay the ascending frame to said first server. In addition, on receipt of a downlink frame for the attention of said second operator terminal device, said collection gateway places the useful data, provided in the downlink frame, in the buffer assigned to said second operator terminal device. Thus, the chances for the terminal devices of the second operator that their communications in the communication system take place within a given time are increased.
According to a particular embodiment, each collection gateway of the first network which receives, from the first server associated with said collection gateway, an order to deactivate the delegation vis-à-vis a terminal device of the second operator performs the following steps: if the buffer assigned to the second operator's terminal device is empty, confirm with said first server that said collection gateway has deactivated delegation with respect to said second operator's terminal device; and if the buffer assigned to said terminal device of the second operator is not empty, maintain the delegation until said buffer is emptied by construction and transmission of said descending frames by said collection gateway. Thus, deactivation of the delegation is carried out in a simple and consistent manner.
According to a particular embodiment, each collection gateway of the first network having activated the delegation vis-à-vis a terminal device of the second operator increments a value of a counter of descending frames over the constructions of said frames downlink to the attention of said terminal device of the second operator and includes in said downlink frames the incremented value of the downlink frame counter, and when said collection gateway deactivates delegation, said collection gateway notifies the first server of an up-to-date value of the counter of descending frames. Thus, the counting of downlink frames is carried out transparently for the terminal device of the second operator in question.
Another object of the invention is a communication system comprising a first network of the LPWAN type from a first operator and a second network of the LPWAN type from a second operator. The first network comprises: subnetworks each comprising at least one convergence node and communication nodes integrating collection gateways, the subnetworks implementing separate respective transport protocols; a first server, for each subnetwork, responsible for managing said collection gateways included in said subnet, each collection gateway communicating via a single convergence node associated with a single first associated server; and a second server, coupled to the very first server, responsible for controlling the MAC layer for terminal devices communicating via said collection gateways of the first network. The second network comprising: a third server in charge of interfacing a fourth server and a fifth server with the second server of the first network; the fourth server, which implements an application with which at least one terminal device of the second operator exchanges application data within the framework of a service subscription defined with the second operator; and the fifth server, responsible for authenticating any terminal device seeking to join the communication system to benefit from the services of the fourth server. The communication system being arranged, within the framework of a roaming management by multi-network transfer between the first network and the second network, for transporting ascending frames including application data from said at least one terminal device of the second operator to to the fourth server by successive relays of a said first server, of the second server and of the third server when said at least one terminal device of the second operator is authenticated and in addition that said ascending frames are received by at least one collection gateway of the first network. The communication system being further such that each collection gateway of at least one subnet of the first network, which has detected a terminal device of the second operator requesting to join the communication system to benefit from the services of the fourth server, communicates with the fifth server to authenticate said terminal device of the second operator detected, by shorting the first server associated with said collection gateway, the second server and the third server by means of a communication interface also bypassing the associated convergence node at said collection gateway.
According to a particular embodiment of the method and / or of the above-mentioned communication system, a sub-network of the first network is a communication network by carrier currents where said communication nodes are smart electric meters and where each device for convergence is a data concentrator, and another subnetwork of the first network is an Internet access supply network where said communication nodes are residential gateways and where each convergence device is a DSLAM type multiplexer ( "Digital Subscriber Line Access Multiplexer" in English).
Brief Description of the Drawings The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of at least one embodiment, said description being made in relation to the accompanying drawings, among which:
[Fig.l] schematically illustrates a communication system of the Internet of Things according to the state of the art;
[Fig.2] schematically illustrates the exchange of messages occurring in the communication system of the Internet of Things in Fig. 1;
[Fig.3A] schematically illustrates a communication system of the Internet of Things in which the present invention can be implemented;
[Fig.3B] schematically illustrates a subnet of the communication system of the Internet of Things in Fig. 3A;
[Fig.3C] schematically illustrates another subnet of the communication system of the Internet of Things in Fig. 3A;
[Fig.4] schematically illustrates a communication node of a subnet of the communication system of the Internet of Things in Fig. 3A;
[Fig.5] schematically illustrates a hardware architecture of a communication device in the communication system of the Internet of Things in FIG. 3A;
[Fig.6] schematically illustrates the exchange of messages occurring in the communication system of the Internet of Things in Fig. 3A;
[Fig.7A] schematically illustrates a first encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.7B] schematically illustrates a second encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.7C] schematically illustrates a third encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.7D] schematically illustrates a fourth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.8A] schematically illustrates a fifth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.8B] schematically illustrates a sixth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.8C] schematically illustrates a seventh message encapsulation used in the communication system of the Internet of Things in Fig. 3A;
[Fig.8D] schematically illustrates an eighth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.9A] schematically illustrates a ninth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.9B] schematically illustrates a tenth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.9C] schematically illustrates an eleventh message encapsulation used in the communication system of the Internet of Things in Fig. 3A;
[Fig.9D] schematically illustrates a twelfth message encapsulation used in the communication system of the Internet of Things in Fig. 3A;
[Fig.lOA] schematically illustrates a thirteenth message encapsulation used in the communication system of the Internet of Things in Fig. 3A;
[Fig.lOB] schematically illustrates a fourteenth encapsulation of messages used in the communication system of the Internet of Things in Fig. 3A;
[Fig.ll] schematically illustrates a delegation activation algorithm;
[Fig. 12] schematically illustrates an algorithm for upward frame processing; and [fig. 59 13] schematically illustrates a downlink frame processing algorithm.
DETAILED DESCRIPTION OF EMBODIMENTS [0062] FIG. 3A schematically illustrates an Internet of Things communication system in which the present invention can be implemented. The communication system of the Internet of Things in Fig. 3A partly takes over the communication system of the Internet of Things in Fig. 1. The first network however includes a plurality of subnetworks 100, 101, 102 each comprising at least one convergence node device and communication nodes integrating LPWAN technology collection gateways. This aspect is detailed below in relation to Figs. 3B and 3C. The subnets 100, 101, 102 implement separate respective transport protocols. There can be in the first network several subnets which implement the same transport protocol as soon as the first network also includes a different transport protocol subnetwork. There is a first FNS server 131, 132, 133 for each subnet 100, 101, 102. Each collection gateway of the first network communicates with a single first FNS server 131, 132, 133 associated via a single associated convergence node. .
[0062] FIG. 3A shows, purely by way of illustration, another terminal device 111 in roaming by multi-network transfer. This aims to show that the ascending frames transmitted by each terminal device 110, 111 can be picked up by collection gateways of the first network which belong to distinct sub-networks.
Unlike the communication system of the Internet of Things in FIG. 1, the Internet of Things communication system of FIG. 3A has connections between the collection gateways of at least one subnet 100, 101, 102 of the first network on one side and the fifth JS 160 server of the second network on the other side. This aspect is detailed below in relation to FIG. 4. It should be noted that the collection gateways of one or more subnets, or of all the subnets 100, 101, 102, can include these connections with the fifth JS server 160. If one or more subnets, and their connections with their first FNS servers 131, 132, 133 respectively, have higher latency performance than those of the other subnets of the first network, so said collection gateways can avoid setting up a direct connection with the fifth JS 160 server. It is considered subsequently, for the sake of simplification, that each collection gateway of the first subnet has a direct connection to the fifth JS 160 server.
The fifth JS 160 server is declared to each of the collection gateways of the first network, which are thus connected to the fifth JS 160 server. This declaration of the fifth JS 160 server to each of the collection gateways of the first network is made following a roaming agreement between the first operator and the second operator. The same type of communication medium can be used between the collection gateways of the first network and the fifth JS 160 server as between said collection gateways and the first FNS server 131, 132, 133 with which said collection gateways are respectively associated. Another type of communication medium can however be used.
As detailed below, this direct relationship between the collection gateways of the first network and the fifth JS 160 server simplifies the exchange of messages by short-circuiting the first FNS 131, 132, 133, second SNS 134 and third HNS 140 servers, and therefore reduce the latency induced, when the terminal device 110, 111 joins in roaming by multi-network transfer the communication system. Each collection gateway of the first network further includes a communication interface for communicating with the fifth JS server 160 which also short-circuits the convergence node via which said collection gateway communicates with the first FNS server 131, 132, 133 which it is associated. This aspect is detailed below in relation to FIG. 4.
The declaration of the fifth JS 160 server to each of the collection gateways of the first network consists in providing the identifier, called JoinEUI in the LoRaWAN 1.1 specifications, which uniquely identifies the fifth JS 160 server. As a reminder, this identifier is included by the terminal device 110, 111 in the JOIN-REQ message that said terminal device 110, 111 transmits to join the communication system, and it is therefore necessary for each collection gateway of the first network to know it beforehand in order to make the link between the terminal device 110, 111 while roaming and the fifth JS 160 server.
In a particular embodiment, following this declaration, each of the collection gateways of the first network then contacts the sixth DNS server, which provides them with an address for contacting the fifth JS 160 server according to the identifier unique in question.
In a particular alternative embodiment, the declaration is such that the unique identifier in question is provided in association with the address for contacting the fifth JS 160 server.
In a particular embodiment, the declaration is first made to each first FNS server 131, 132, 133 following the roaming agreement concluded between the first operator and the second operator, and each first FNS server 131, 132, 133 forwards the declaration in question to each of the collection gateways with which said first FNS server 131, 132, 133 is associated. This simplifies the declaration of the fifth JS 160 server. Note that one possibility is that each first FNS server 131, 132, 133 contacts the sixth DNS server, which provides it with the address to contact the fifth JS 160 server according to the 'unique identifier in question, and that each first FNS server 131, 132, 133 then transmits to each of the collection gateways associated with it the unique identifier in question, in association with the address for contacting the fifth JS server 160.
Note that the communications between the collection gateways and any server, and between the servers themselves, are preferably based on the IP protocol ("Internet Protocol" in English), as defined in the normative document RFC 791.
This aspect is detailed below in relation to Figs. 7A to 7D, 8A to 8D, 9A to 9D, 10A and 10B.
[0071] FIG. 3B schematically illustrates the subnet 100 of the communication system of the Internet of Things in FIG. 3A. The sub-network 100 includes communication nodes 170, 171, 172, 173 which are connected to a convergence node 174 of the sub-network 100. The communication nodes 170, 171, 172, 173 respectively integrate GW collection gateways 123, 124, 125, 126. Certain communication nodes 172 can act as a relay between other communication nodes 170, 171 and the convergence node 174. The subnetwork 100 potentially includes one or more other convergence nodes 175 to which are still attached other communication nodes (not shown for the sake of simplification). Each convergence node 174, 175 of the sub-network 100 is attached to the first FNS server 131. The sub-network 100 is preferably a communication network with carrier currents (“Powerline Communication” in English), the communication nodes 170, 171 , 172, 173 are smart meters SM (“Smart Meters” in English) responsible for supervising the distribution and electrical consumption of associated electrical installations, and the convergence nodes 174, 175 are DC data concentrator devices (“ Data Concentrators "in English) in charge of interfacing said SM smart meters with a server (not shown) in charge of configuring said SM smart meters and collecting metering readings supplied by said SM electric meters. For example, the communications between the communication nodes 170, 171, 172, 173 and the convergence node 174 are supported by the G3-PLC protocol or by the PRIME protocol.
[0072] FIG. 3C schematically illustrates another subnet 101, 102 of the Internet of Things communication system of FIG. 3A. The sub-network 101, 102 includes communication nodes 180, 181, 182 which are connected to a convergence node 190 of the sub-network 101, 102. The communication nodes 180, 181, 182 respectively integrate GW collection gateways 127, 128, 129. The subnetwork 100 potentially includes one or more other convergence nodes 191 to which are still attached other communication nodes (not shown for the sake of simplification). Each convergence node 190, 191 of the sub-network 101 is linked to the first FNS server 132. Each convergence node 190, 191 of the sub-network 102 is linked to the first FNS server 133. The sub-networks 101, 102 are preferably networks of providing access to the Internet, the communication nodes 180, 181, 182 are routers in the form of RGW residential gateways and the convergence nodes 190, 191 are DSLAM digital subscriber line access multiplexers (“ Digital Subscriber Line Access Multiplexer ”. For example, the communications between the communication nodes 180, 181, 182 and the convergence node 190 in the subnet 101 are supported by the asymmetric digital subscriber line protocol ADSL ("Asymmetric Digital Subscriber Line" in English) , ADSL2 or ADSL2 +. For example, the communications between the communication nodes 180, 181, 182 and the convergence node 190 in the subnet 102 are supported by the very high-speed digital subscriber line protocol VDSL ("Very-high-bit-rate" Digital Subscriber Line ”or VDSL2.
[0073] FIG. 4 schematically illustrates a COM 200 communication node of a subnet of the communication system of the Internet of Things in FIG. 3A, as for example introduced in Figs. 3B and 3C. The COM 200 communication node integrates one or more electronic components executing GW 440 collection gateway functionalities. The COM 200 communication node additionally integrates one or more electronic components executing MFC 430 main functionalities, which are linked to the counting of electricity consumed in the example of sub-network 100 described in relation to FIG. 3B, and which are linked to the routing of Internet access provision in the example of a subnet 101, 102 described in relation to FIG. 3C. The COM 200 communication node can also integrate auxiliary functionalities in the electronic component or components executing the main MFC 430 functionalities.
Or the electronic components executing the main functionalities MFC 430 are connected to a first communication interface IF1 410 which makes it possible to communicate with the convergence node to which said communication node COM 200 is attached, and can be connected to at least a second communication interface IF2 411, to allow communication within the framework of the main functionalities MFC 430 and possibly of the above-mentioned auxiliary functionalities.
Or the electronic components executing the GW 440 collection gateway functionalities are connected to the first communication interface IF 1,410, which makes it possible to communicate with the first FNS server 131, 132, 133 via the convergence node to which said COM 200 communication node is attached. The electronic component or components executing the GW 440 collection gateway functionalities are also connected to a third communication interface IF1 412, to allow communication by radio with the terminal devices 110, 111. The electronic component or components executing the functionalities GW 440 collection gateways are also connected to a fourth communication interface IF4 413, to allow communication with the fifth JS 160 server by short-circuiting the first FNS servers 131, 132, 133, second SNS server 134 and third server HNS 140, as well as the convergence node to which said COM 200 communication node is attached.
[0076] FIG. 5 schematically illustrates an example of hardware architecture of a communication device of the Lig communication system. 3A. Each terminal device and / or each communication node integrating a collection gateway and / or each convergence node and / or each core network server can be constructed on the basis of such a hardware architecture.
The communication device comprises, connected by a communication bus 510: a processor or CPU ("Central Processing Unit" in English) 501; a random access memory RAM (“Random Access Memory” in English) 502; a read only memory (ROM) 503; a storage unit or a storage medium reader, such as an SD card reader (“Secure Digital” in English) 504 or a hard disk HDD (“Hard Disk Drive” in English); one or more IL 505 communication interfaces.
The processor 501 is capable of executing instructions loaded in the RAM memory 502 from the ROM memory 503, from an external memory, from a storage medium, or from a communication network. When the communication device in question is powered up, the processor 501 is capable of reading instructions from the RAM 502 and executing them. These instructions form a computer program causing the implementation, by the processor 501, of all or part of the algorithms and steps described here in relation to the communication device in question.
Thus, all or part of the algorithms and steps described here can be implemented in software form by execution of a set of instructions by a programmable machine, such as a DSP ("Digital Signal Processor" in English) or a microcontroller. All or part of the algorithms and steps described here can also be implemented in hardware form by a machine or a dedicated component, such as an LPGA (“Lield-Programmable Gate Array” in English) or an ASIC (“Application-Specific Integrated Circuit” " in English). In general, the communication device in question comprises electronic circuitry adapted and configured to implement the algorithms and steps described here in relation to the communication device in question.
[0080] FIG. 6 schematically illustrates exchanges of messages occurring in the communication system of the Internet of Things in FIG. 3, when the terminal device 110 (for example) joins in roaming by multi-network transfer the communication system. These messages are exchanged in respective frames.
In a step 601, the terminal device 110 transmits a JOIN-REQ message via its radio interface. This step is identical to step 201 described in relation to FIG. 2. This JOIN-REQ message therefore includes a unique identifier for the terminal device 110, called DevEUI in the LoRaWAN 1.1 specifications, as well as the unique identifier for the fifth JS 160 server.
This JOIN-REQ message is picked up by at least one collection gateway from the first network. Consider that this JOIN-REQ message is received by the collection gateway 128. In a step 602, the collection gateway 128 directly relays the JOIN-REQ message to the fifth JS server 160, in the form of a JREQ message as above mentioned. The first FNS server 132 with which the collection gateway 128 is associated, the second SNS server 134 and the third HNS server 140 are thus short-circuited. The same goes for the DSLAM 190 convergence node. Thanks to the identifier which is contained in the JOIN-REQ message and which uniquely identifies the fifth JS server 160, the collection gateway 128 detects that the terminal device 110 is when roaming and that the core network of the second operator is responsible for verifying that the terminal device 110 has a suitable subscription, and preferably for authenticating the terminal device 110, that is to say confirming that the terminal device having transmitted the JOIN-REQ message is effectively the terminal device 110 corresponding to the unique identifier provided.
In the particular case of the message formats defined in the LoRaWAN 1.1 specifications, the JREQ message takes the form of a JoinReq message. The collection gateway 128 copies in a dedicated field of the JoinReq message the unique identifier of the terminal device, called DevEUI, that the terminal device 110 while roaming has registered in the Join-request message transmitted in step 601. In addition, the MACversion, DLSettings and RxDelay fields are set to default values. Note that the DLSettings and RxDelay values can be modified later with the terminal device 110 by MAC command from the second SNS server 134, to adjust them to the actual needs of the core network of the first operator.
On receipt of the JREQ message, the fifth JS 160 server verifies that the terminal device 110 has a subscription suitable for accessing the services of the fourth AS 150 server while roaming by multi-network transfer. Preferably, the fifth JS server 160 performs the authentication of the terminal device 110. In a particular embodiment, in the event of successful authentication, the fifth JS server 160 obtains (eg, generates) the security keys necessary for the terminal device 110 to communicate encrypted in the communication system and benefit from the services of the fourth AS 150 server.
The fifth JS 160 server constructs a JANS message which includes a JOIN-ACC message to be relayed to the terminal device 110. When the subsequent communications with the terminal device 110 must be encrypted and the terminal device 110 is effectively authenticated by the fifth JS 160 server, the JOIN-ACC message also includes the information allowing the terminal device 110 to obtain the security keys making it possible to secure exchanges with the terminal device 110. The JOIN-ACC message preferably also includes, in encrypted form with a known key of the terminal device 110, the security key to be used to communicate with the fourth AS 150 server. This last security key is encrypted because it does not have to be known to the collection gateways of the first network, nor of the core network of the first operator. The JANS message can also include, other than in the JOIN-ACC message, the security keys making it possible to secure exchanges with the terminal device 110 (with the exception therefore of the security key allowing the terminal device 110 to communicate with the fourth AS 150 server). This simplifies the recovery of these security keys by the collection gateway to which the JANS message will be addressed.
When the message formats defined in the LoRaWan 1.1 specifications are used, the fifth JS 160 server can modify the default values proposed in the MACversion, DLSettings and RxDelay fields of the JREQ message transmitted by the collection gateway 128. C ' this is particularly the case when the roaming agreements concluded between the first operator and the second operator define default values to be used and these default values are written to the memory of the fifth JS 160 server of the second operator without it there is a need to record them in memory of the first operator's collection gateways. As already indicated, the DLSettings and RxDelay values can be subsequently modified with the terminal device 110 by MAC command from the second SNS server 134, to adjust them to the actual needs of the core network of the first operator.
In a particular embodiment, to be able to communicate in the communication system, the terminal device 110 must be dynamically assigned an address, called DevAddr in the LoRaWan 1.1 specifications. Within the framework of a roaming according to the architecture of FIG. 1, this address is assigned by the second SNS server 134. Here, since the second SNS server 134 is not involved in relaying the JOIN-REQ message, it is up to the fifth JS 160 server to assign this address. To do this, the management of a predetermined subset of the address range of the first operator is exclusively entrusted to the fifth JS 160 server of the second operator as part of the roaming agreement. We speak of provisioning of addresses. The fifth JS 160 server then assigns an address of said predetermined subset of the address range of the first operator when said fifth JS 160 server successfully authenticates a terminal device while roaming, and indicates in the JOIN-ACC message which address has been thus assigned. This address provisioning can be configured with the second SNS 134 server and the fifth JS 160 server following the roaming agreement. As a variant, the address range of the first operator, the management of which is entrusted to the fifth JS server 160 of the second operator is negotiated by exchange of messages between the second SNS server 134 and the fifth JS 160 server.
The fifth JS 160 server must then distinguish the cases where said fifth JS 160 server must assign an address (terminal device while roaming) from cases where said fifth JS 160 server must not assign an address (terminal device which does not is not roaming). To do this, the format of the JREQ messages sent by the collection gateways can be different from the format of the JREQ messages sent by the third HNS server 140, i.e., of different format. A specific value of a JREQ message field can alternatively be reserved for collection gateways and prohibited to the third HNS server 140. In another variant, the fifth JS server 160 having knowledge of the address of the third HNS server 140, the fifth JS server 160 is capable of detecting that a received JREQ message comes from equipment other than the third HNS server 140 and deciding if necessary to allocate an address among the provisioned addresses.
Then, in a step 603, the fifth JS server 160 transmits the JANS message in response to the JREQ message received in step 602. The fifth JS server 160 thus responds directly to the collection gateway 128.
Then, in a step 604, the collection gateway 128 relays by radio the JOIN-ACC message to the attention of the terminal device 110. The collection gateway 128 recovers in the JOIN-ACC message the address assigned to terminal device 110 by the fifth DNS server 160. The collection gateway 128 also recovers in the JANS message, if necessary, the security keys useful to the first core network. In a step 605, the collection gateway 128 informs the core network of the first operator that the JOIN-ACC message has been transmitted to the terminal device 110. To do this, the collection gateway 121 transmits to the first FNS server 132 a notification message JOIN-NOT including the unique identifier of the terminal device 110, as well as the address assigned by the fifth JS 160 server to the terminal device 110. The core network of the first network is thus informed of the presence of the terminal device 110 while roaming.
In the event that subsequent communications with the terminal device 110 must be encrypted, the JOIN-NOT notification message includes the security keys recovered by the collection gateway 128. This allows the core network of the first network to authenticate and to decipher the communications of the terminal device 110 on behalf of the second operator within the framework of roaming by multi-network transfer. Instructs the first FNS server 132 to forward the appropriate information to the second SNS server 134 (not shown in Fig. 6). In the case where a delegation (as described below) is set up, this also allows the core network of the first network to entrust the delegation to another collection gateway.
In the case where the JOIN-REQ message is received by at least one other collection gateway of the first network, each said other collection gateway also relays the JOIN-REQ message to the fifth JS 160 server, in the same way as described above with respect to the collection gateway 128. In the case of a Join-request message according to the LoRaWAN 1.1 specifications, it is for example possible for the fifth JS 160 server to detect this situation by noting that the field "Nonce" has the same value in the various JOIN-REQ messages thus received. The fifth JS 160 server is then in charge of performing the deduplication of the JOINREQ messages thus received and of deciding which collection gateway to answer among the collection gateways which relayed the JOIN-REQ message. In a particular embodiment, the fifth JS 160 server responds to the very first collection gateway which relayed the JOIN-REQ message to it. As a variant, the fifth JS server 160 responds to a collection gateway randomly selected from the collection gateways having relayed the JOIN-REQ message. In another variant, each collection gateway relaying the JOIN-REQ message indicates, in association, a signal reception strength indicator RSSI ("Received Signal Strength Indicator") coming from the terminal device 110, and the fifth server JS 160 responds to the collection gateway which provides the best indicator of signal reception strength from the terminal device 110.
Thus, by ensuring communications directly between the collection gateways of the first operator and the fifth JS 160 server of the second operator, the latency between the transmission of the JOIN-REQ message by the terminal device 110 while roaming and the reception of the message JOIN-ACC by said terminal device 110 is reduced.
When the terminal device 110 has received the JOIN-ACC message which confirms that the authentication has been successful, the terminal device 110 has joined the communication system. The terminal device 110 is then authorized to carry out upward communications intended for the fourth server AS 150 and to receive downward communications from the core network. Communications between the terminal device 110 and the fourth AS 150 server are carried out by successive relays from the DSLAM 190 convergence node and from the first FNS 132, second SNS 134 and third HNS 140 servers to the fourth AS 150 server.
When the communications are encrypted, the ascending communications are authenticated by the core network of the first network using the security keys provided by the fifth JS server 160, typically by the second SNS server 134 after relay by the first FNS server 132. The content of the upward communications is then relayed by the second SNS server 134 to the third HNS server 140 which then relays said content to the fourth AS server 150 for application processing. In charge of managing the MAC layer, the second SNS server 134 acknowledges the ascending frames from the terminal device 110 while roaming and relays the data received from the fourth AS server 150 to l until said terminal device 110. attention of said terminal device 110 while roaming and, if necessary, performs the encryption of the downlink frames.
The questions of latency are less preponderant in the case of the processing of said ascending frames because there is no intervention of the fifth JS 160 server whose processing, in particular for authentication and obtaining the security keys , have a significant impact when the terminal device joins the communication system. However, a particular embodiment also makes it possible to improve the latency in the context of the processing of ascending frames and of the management of descending frames. The management of the acknowledgments of the ascending frames is then in particular entrusted to a collection gateway. We then speak of "delegation". This delegation approach is particularly advantageous in the case of terminal devices which listen to the communication medium essentially during reception windows defined according to the instants of transmission of their ascending frames, that is to say the terminal devices of " Class A ”and“ Class B ”in the LoRaWAN 1.1 specifications. This aspect is detailed below in relation to Figs. 11 to 13.
[0097] FIG. 7A schematically illustrates a first encapsulation of messages used in the example where the subnetwork 100 is a carrier current network conforming to the G3-PLC protocol. The lower protocol layer is that of the G3-PLC protocol, surmounted by a protocol layer of type 6LowPAN (“IPv6 Low power Wireless Personal Area Networks” in English), surmounted by a protocol layer of type IPv6, surmounted by a protocol layer of type UDP ("User Datagram Protocol" in English). Note that the Transmission Control Protocol (TCP) can be used in place of the UDP protocol. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the GW collection gateway integrated into a smart counter SM to the convergence node DC to which said smart counter SM is attached. LoRaWAN messages are accompanied by containers (“container” in English) specifying the IP addresses of the GW collection gateways respectively concerned and other information M, such as indicators of reception strength of signal RSSI and information representative of the respective times. of receiving said LoRaWAN messages from the respective terminal devices.
[0098] FIG. 7B schematically illustrates a second encapsulation of messages used in the example where the subnetwork 100 is a carrier current network, for example in accordance with the G3-PLC protocol. The lower protocol layer is that of a mobile Internet access protocol (for example of the 2G, 3G or 4G type), overcome by a protocol layer of IPv6 type, surmounted by a protocol layer of TCP type, surmounted a protocol layer of HTTPS type (“HyperText Transfer Protocol Secure” in English). These layers form a protocol stack encapsulating LoRaWAN messages relayed from the DC convergence node considered towards the first LNS server 131. LoRaWAN messages are accompanied respectively by the same containers as in the Lig. 7A.
[0099] FIG. 7C schematically illustrates a third message encapsulation used in the example where the subnetwork 100 is a carrier current network, for example in accordance with the G3-PLC protocol. The lower protocol layer is that of the Lig mobile Internet access protocol. 7B, surmounted by an IPv6 type protocol layer, surmounted by a TCP type protocol layer, surmounted by an HTTPS type protocol layer. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the first LNS server 131 to the convergence node DC considered. LoRaWAN messages are accompanied by respective containers specifying the IP addresses of the GW collection gateways respectively concerned and TxD information representative of the respective times at which said LoRaWAN messages are supposed to be transmitted to the terminal devices concerned.
[0100] FIG. 7D schematically illustrates a fourth message encapsulation used in the example where the subnetwork 100 is a carrier current network conforming to the G3-PLC protocol. The lower protocol layer is that of the G3-PLC protocol, surmounted by a protocol layer of type 6LowPAN, surmounted by a protocol layer of type IPv6, surmounted by a protocol layer of type UDP, as for FIG. 7A. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the convergence node DC concerned to the smart meter SM integrating the integrated collection gateway GW concerned. LoRaWAN messages are accompanied by containers specifying the TxD information representative of the respective times at which said LoRaWAN messages are supposed to be transmitted to the terminal devices concerned.
[0101] FIG. 8A schematically illustrates a fifth message encapsulation used in the example where the subnet 101 is an ADSL, ADSL2 or ADSL2 + type Internet access supply network. The lower protocol layer is that of the ADSL, ADSL2 or ADSL2 + protocol, surmounted by a protocol layer of AAL5 type (“Asynchronous Transfer Mode Adaptation Layer 5” in English), surmounted by a protocol layer of IPv6 type, surmounted by a pro layer tocol type TCP. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the collection gateway integrated into a RGW residential gateway to the DSLAM convergence node to which said RGW residential gateway is attached. LoRaWAN messages are accompanied by containers specifying the IP addresses of the respective collection gateways and other information M, such as the RSSI signal reception strength indicators and the information representative of the respective times of reception of said LoRaWAN messages from respectively affected terminal devices.
[0102] FIG. 8B schematically illustrates a sixth message encapsulation used in the example where the subnet 101 is an ADSL, ADSL2 or ADSL2 + type Internet access supply network. The sixth encapsulation, which forms a protocol stack encapsulating LoRaWAN messages relayed from the DSLAM convergence node considered towards the first LNS server 132, is identical to that of the Lig. 7B.
[0103] FIG. 8C schematically illustrates a seventh message encapsulation used in the example where the subnet 101 is an ADSL, ADSL2 or ADSL2 + type Internet access supply network. The seventh encapsulation, which forms a protocol stack encapsulating LoRaWAN messages relayed from the first LNS 132 server to the DSLAM convergence node concerned, is identical to that of the Lig. 7C.
[0104] FIG. 8D schematically illustrates an eighth message encapsulation used in the example where the subnet 101 is an ADSL, ADSL2 or ADSL2 + type Internet access supply network. The lower protocol layer is that of the ADSL, ADSL2 or ADSL2 + protocol, surmounted by a protocol layer of type AAL5, surmounted by a protocol layer of type IPv6, surmounted by a protocol layer of type TCP, as for FIG. 8A. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the DSLAM convergence node concerned to the RGW residential gateway integrating the concerned integrated GW collection gateway. LoRaWAN messages are accompanied by containers specifying the TxD information representative of the respective times at which said LoRaWAN messages are supposed to be transmitted to the terminal devices concerned.
[0105] FIG. 9A schematically illustrates a ninth message encapsulation used in the example where the subnet 102 is a network for providing Internet access of the VDSL or VDSL2 type. The lower protocol layer is that of the VDSL or VDSL2 protocol, surmounted by an Ethernet type protocol layer, surmounted by an IPv6 type protocol layer, surmounted by a TCP type tochool layer. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the collection gateway integrated into a RGW residential gateway to the DSLAM convergence node to which said RGW residential gateway is attached. LoRaWAN messages are accompanied by containers specifying the IP addresses of the respective collection gateways and other information M, such as the RSSI signal reception strength indicators and information representative of the respective times of reception of said LoRaWAN messages originating from the affected terminal device. [0106] FIG. 9B schematically illustrates a tenth message encapsulation used in the example where the subnet 102 is a network for providing Internet access of the VDSL or VDSL2 type. The tenth encapsulation, which forms a protocol stack encapsulating LoRaWAN messages relayed from the DSLAM convergence node considered towards the first LNS server 133, is identical to that of the Lig. 7B. [0107] FIG. 9C schematically illustrates an eleventh message encapsulation used in the example where the subnet 102 is a network for providing Internet access of the VDSL or VDSL2 type. The eleventh encapsulation, which forms a protocol stack encapsulating LoRaWAN messages relayed from the first LNS 133 server to the DSLAM convergence node concerned, is identical to that of the
Lig. 7C.
[0108] FIG. 9D schematically illustrates a twelfth message encapsulation used in the example where the subnet 102 is a network for providing Internet access of the VDSL or VDSL2 type. The lower protocol layer is that of the VDSL or VDSL2 protocol, surmounted by an Ethernet type protocol layer, surmounted by an IPv6 type protocol layer, surmounted by a TCP type protocol layer, as in FIG. 9A. These layers form a protocol stack encapsulating LoRaWAN messages relayed from the DSLAM convergence node concerned to the RGW residential gateway integrating the concerned integrated GW collection gateway. LoRaWAN messages are accompanied by containers specifying the TxD information representative of the respective times at which said LoRaWAN messages are supposed to be transmitted to the terminal devices concerned.
[0109] FIG. 10A schematically illustrates a thirteenth message encapsulation used in the Internet of Things communication system of FIG. 3A, when a GW collection gateway communicates directly with the fifth JS 160 server. The lower protocol layer is that of a mobile Internet access protocol (for example of the 2G, 3G or 4G type), overcome by an IPv6 type protocol layer, surmounted by a TCP type protocol layer, surmounted by an HTTPS type protocol layer. These layers form a protocol stack encapsulating JREQ messages, as mentioned in relation to FIG. 6, transmitted from the GW collection gateways respectively concerned to the fifth JS 160 server. The JREQ messages are accompanied by respective containers specifying the IP addresses of the GW collection gateways respectively concerned.
[0110] FIG. 10B schematically illustrates a fourteenth encapsulation of messages used in the Internet of Things communication system of FIG. 3A, when the fifth JS server 160 communicates directly with a GW collection gateway. The lower protocol layer is that of the mobile Internet access protocol in FIG. 10A, surmounted by an IPv6 type protocol layer, surmounted by a TCP type protocol layer, surmounted by an HTTPS type protocol layer. These layers form a protocol stack encapsulating JANS messages transmitted from the fifth JS 160 server to the GW collection gateways respectively concerned. The JANS messages are accompanied by respective containers specifying the IP addresses of the GW collection gateways respectively concerned and TxD information representative of the respective times at which the corresponding JOIN-ACC messages are supposed to be transmitted to the terminal devices concerned.
Note that as a variant, it is possible to use the IPv4 protocol instead of the IPv6 protocol for all the protocol encapsulations relating to FIGS. 7A to 10B, except for Figs. 7A and 7D which only include the IPv6 protocol.
[0112] FIG. 11 schematically illustrates a delegation activation algorithm vis-à-vis a terminal device roaming by multi-network transfer, in a particular embodiment. The algorithm in Fig. It is implemented by each collection gateway of the first network. Consider for illustrative purposes that the algorithm of Fig. 11 is implemented by the collection gateway 128.
In a step 1101, the collection gateway 128 detects a roaming terminal device to be managed. This is the case when the collection gateway 128 has transmitted a JREQ message to the fifth JS 160 server for said terminal device while roaming and has received in return a JANS message from the fifth JS 160 server. We can then speak of " elected collection gateway ”since it was selected, here by the fifth JS 160 server, for setting up the delegation. Another case arises when the first FNS server 132, or the second SNS server 134, subsequently decides to entrust the delegation to another GW collection gateway, in which case the first FNS 132 server informs the GW collection gateway to which the delegation was previously entrusted, awaits an acquittal. Then, the first FNS server 132, or the second SNS server 134 via the first FNS 131, 133 concerned, sends to this other collection gateway GW an order to activate the delegation for said terminal device in roaming by multi-transfer. networks. Indeed, the delegation vis-à-vis a terminal device can only be entrusted to one GW collection gateway at a time, to avoid any conflict of acknowledgment of the ascending frame.
In a step 1102, the collection gateway 128 internally activates the delegation for the terminal device in roaming in question. The collection gateway 128 thus keeps track of having to acknowledge, on behalf of the core network of the first network, the ascending frames received from said terminal device while roaming.
In the context of the activation of the delegation, the collection gateway 128 initializes a buffer ("buffer" in English) dedicated to downlink transmissions to the terminal device in question. This buffer is therefore assigned to said terminal device while roaming and makes it possible to make asynchronous, from the point of view of the core network, the downlink transmissions intended for said terminal device while roaming with respect to the upward transmissions originating from said terminal device while roaming. In the case where the first FNS server 132 seeks to entrust the delegation to another collection gateway GW, the collection gateway 128 checks whether the buffer associated with the delegation in question is empty or not. In other words, the collection gateway 128 verifies whether data useful for the attention of the terminal device in roaming in question is still awaiting transmission. If the buffer is empty, the collection gateway 128 is authorized to deactivate the delegation and send an acknowledgment to the first FNS server 130; otherwise, the collection gateway 128 must continue to acknowledge the ascending frames from said terminal device while roaming until the buffer becomes empty. Once the buffer is empty, the collection gateway 128 stops acknowledging the ascending frames from said terminal device while roaming, transmits the acknowledgment to the first FNS server 132, and releases the buffer which was assigned to the delegation in question. In some embodiments, upstream frame counters are maintained by the terminal devices and downlink frame counters are maintained by the core network. The current values of these counters are indicated respectively in dedicated fields of the ascending frames and the descending frames. In the case of a delegation, the downlink frame counter associated with the roaming terminal device to which the delegation applies is maintained by the elected GW collection gateway. Then, in the acknowledgment transmitted to the first FNS server 132, the collection gateway 128 includes the value of the downlink frame counter. The first FNS server 132, or the SNS server 134 if applicable, informs the other GW collection gateway to which the delegation is entrusted, so that this other GW collection gateway can ensure the counting of downlink frames. This ensures that the delegation remains transparent for said terminal device while roaming.
[0116] FIG. 12 schematically illustrates an upward frame processing algorithm. The algorithm in Fig. 12 is implemented by each collection gateway of the first network, in a particular embodiment. Consider for illustrative purposes that the algorithm of Fig. 12 is implemented by the collection gateway 128.
In a step 1201, the collection gateway 128 receives an ascending frame from a terminal device. The ascending frame specifies the address of the terminal device from which said ascending frame emanates.
In a step 1202, the collection gateway 128 verifies whether the terminal device is a roaming terminal device for which the delegation has been activated with the collection gateway 128. If this is the case, a step 1204 is carried out ; otherwise, a step 1203 is carried out.
In step 1203, the collection gateway 128 forwards the ascending frame to the core network, namely to the first FNS server 132, so that said ascending frame can reach the fourth AS server 150 in order to process the application content. The collection gateway 128 here simply serves as a relay and temporarily keeps track of a return expected from the core network with respect to said ascending frame, at least to acknowledge said ascending frame and possibly to provide additional useful data.
The collection gateway 128 keeps track of the reception of said ascending frame and of the moment at which said ascending frame was received, so as to be able later to determine when to transmit in response a descending frame comprising, at least, an acknowledgment of said ascending frame. When the collection gateway 128 subsequently receives from the core network the downlink frame to be forwarded to the terminal device in question in response to said ascending frame, the core network provides time information representative of a duration and the collection gateway 128 adds said duration at the time when said ascending frame was received, to determine when to transmit said descending frame.
As a variant, the collection gateway 128 programs ("schedule" in English) at least one reception window for said terminal device, in which the collection gateway 128 is supposed to relay a downlink frame which will be subsequently supplied by the network. heart. The collection gateway 128 then monitors to receive a downlink frame to be forwarded to the terminal device in question in response to said ascending frame within appropriate times to respect a said reception window thus programmed.
In step 1204, the collection gateway 128 must acknowledge, on behalf of the core network, the upward frame received in step 1201. This means that the terminal device concerned is roaming and that the collection gateway 128 has the delegation to anticipate the acknowledgments to said terminal device. When the acknowledgment must be made in a said reception window defined after an instant of transmission of said ascending frame, the collection gateway 128 ensures that said terminal device is listening to the communication medium. The collection gateway 128 checks whether the buffer associated with said terminal device contains useful data provided by the core network for the attention of said terminal device. If the buffer does not contain such useful data, the collection gateway 128 constructs a downlink frame including the abovementioned acknowledgment and transmits the downlink frame thus constructed to said terminal device at the appropriate time. Otherwise, the collection gateway 128 constructs a downlink frame including the abovementioned acknowledgment and also including data stored in the buffer. This data is then erased from the buffer, and the collection gateway 128 transmits the downlink frame thus constructed to said terminal device at the appropriate time, and step 1205 is then carried out.
In the particular embodiment where the communications with the terminal device in question are encrypted, the collection gateway 128 authenticates the terminal device by decoding an integrity code included in the ascending frame received in step 1201 thanks to security keys associated with said terminal device. This integrity code is called MIC ("Message Integrity Code" in English) in the LoRaWAN 1.1 specifications. If authentication fails, the collection gateway 128 discards the upstream frame and interrupts the execution of the Lig algorithm. 12. In addition, when the collection gateway 128 must encrypt the downlink frame constructed, the collection gateway 128 uses the security keys associated with said terminal device while roaming to encrypt said downlink frame, before transmitting said downlink frame in encrypted form. The descending frame in encrypted form then also includes an integrity code authenticating the core network, on behalf of which the collection gateway 128 acts.
In step 1205, the collection gateway 128 forwards the ascending frame or the data contained in the ascending frame to the core network, so that said ascending frame can reach the fourth AS server 150 in order to process the content. The collection gateway 128 can also only relay data outside of delegation. By non-delegation data is meant data which does not relate to a functionality delegated to the collection gateway 128. The collection gateway 128 can thus for example not propagate the integrity code contained in the upward frame received from said terminal device while roaming . This data can be encrypted by the collection gateway 128 using a security key also known from the first LNS server 132, for example by using a secure tunnel.
We notice, in view of the algorithm of FIG. 12, that the data contained in an ascending frame can be relayed by several collection gateways which would pick up the ascending frame in question. It is then the responsibility of the first FNS 132 server to perform any appropriate data deduplication.
[0126] FIG. 13 schematically illustrates a downlink frame processing algorithm. The algorithm in Fig. 13 is implemented by each collection gateway of the first network. Consider for illustrative purposes that the algorithm of Fig. 13 is implemented by the collection gateway 128.
In a step 1301, the collection gateway 128 receives a downlink frame coming from the core network. The downlink frame specifies the address of the terminal device for which said downlink frame is intended.
In a step 1302, the collection gateway 128 checks whether the delegation has been activated with respect to said terminal device (in which case the terminal device in question is roaming) or not. If this is the case, a step 1303 is carried out; otherwise, a step 1304 is carried out.
In step 1303, the collection gateway 128 puts the data contained in the downlink frame received in step 1301 in the buffer associated with the roaming terminal device for which said data is intended. We can then speak of “useful data” for the attention of said terminal device while roaming. The downlink frame received in step 1301 then typically has a format other than the downlink frames transmitted by the first FNS server 132 when the delegation mechanism is not activated, since at least the acknowledgments are not managed by the network. heart when the delegation mechanism is activated. The collection gateway 128 will subsequently send the useful data thus received from the core network to the attention of the terminal device in question, when a reception window allows it, more particularly in response to a next upward transmission from said terminal device in roaming.
In step 1204, the collection gateway 128 must relay the downlink frame received in step 1201. Since the delegation is not activated, the collection gateway 128 can relay to the terminal device in question only if there is at least one reception window to come according to the ascending frame which triggered the sending of said descending frame by the core network. In other words, the collection gateway 128 verifies whether said collection gateway 128 had kept a trace that a return was expected from the core network with respect to an ascending frame previously received from said terminal device. If this is the case, a step 1205 is carried out; otherwise, a step 1206 is carried out.
In step 1205, the collection gateway 128 forwards the downlink frame received in step 1201 in a said reception window defined according to an instant of transmission of the ascending frame which triggered the sending of said descending frame by the core network.
In step 1206, the collection gateway 128 is out of time in order to be able to relay the downlink frame to the terminal device in question. The collection gateway 128 therefore throws the downlink frame. It is then the responsibility of the core network to retransmit later the useful data which were contained in said downlink frame.
We also see from the above that transferring part of the control functionality of the MAC layer of the SNS server 134 to the collection gateways of the first network constitutes a significant improvement in terms of latency in situations of roaming by transfer multi-networks in a context where separate transport protocols are used to form the LPWAN type communication network via which Γ multi-network transfer roaming is activated.
We also see from the above that, although it is not necessary to implement the message formats defined in the LoRaWAN protocol in order to benefit from the advantages of the invention, the devices and methods described are largely compatible with the LoRaWAN 1.1 specifications and represent a significant improvement in terms of latency.

权利要求:
Claims (1)
[1" id="c-fr-0001]
[Claim 1]
Claims
Method for managing roaming by multi-network transfer in a communication system comprising a first network of the LPWAN type from a first operator and a second network of LPWAN type from a second operator, the first network comprising:
- sub-networks (100, 101, 102) each comprising at least one convergence node (174, 175; 190, 191) and communication nodes (170, 171, 172; 180, 181, 182) integrating gateways collection (123, 124, 125; 127, 128, 129), the subnets (100, 101, 102) implementing separate respective transport protocols,
- a first server (131, 132, 133), for each subnet (100, 101, 102), responsible for managing said collection gateways (123, 124, 125; 127, 128, 129) included in said sub network (100, 101, 102), each collection gateway communicating via a single convergence node associated with a single first associated server, and
- a second server (134), coupled to the very first server (131, 132, 133), responsible for controlling the MAC layer for terminal devices (110, 111) communicating via said collection gateways (123, 124, 125; 127, 128, 129) of the first network;
the second network comprising:
- a third server (140) in charge of interfacing a fourth server (150) and a fifth server (160) with the second server (134) of the first network,
- the fourth server (150), which implements an application with which at least one terminal device (110, 111) of the second operator exchanges application data within the framework of a service subscription defined with the second operator, and
- the fifth server (160), responsible for authenticating any terminal device (110, 111) seeking to join the communication system to benefit from the services of the fourth server (150);
the method being such that the communication system transports ascending frames including application data from said at least one terminal device (110, 111) from the second operator to the fourth server (150) by successive relays of a said first server ( 131, 132, 133), the second server (134) and the third server (140) when said at least one terminal device (110, 111) of the second operator is authenticated and further that said ascending frames are [Claim 2] [ Claim 3] [Claim 4] [Claim 5] received by at least one collection gateway (123, 124, 125; 127, 128, 129) of the first network, the method being also such that each collection gateway (123, 124, 125; 127, 128, 129) of at least one subnet of the first network, which has detected a terminal device (110, 111) of the second operator requesting to join the communication system to benefit from the services of the fourth server (150), communicates with the fifth server (160) to authenticate said terminal device (110, 111) of the second operator detected, by short-circuiting the first server (131, 132, 133) associated with said collection gateway (123, 124, 125; 127, 128, 129), the second server (134) and the third server (140) by means of a communication interface also bypassing the convergence node associated with said collection gateway (123, 124, 125; 127, 128 , 129).
Method according to claim 1, characterized in that the first network having an address range for all the terminal devices (110, 111) accessing the communication system via the collection gateways (123, 124, 125; 127 , 128, 129) of the first network, the fifth server (160) manages a predetermined subset of addresses from the address range of the first network and assigns an address from said predetermined subset of addresses to any terminal device (110, 111) of the second operator which is roaming by multi-network transfer via the first network and which is authenticated by the fifth server (160).
Method according to either of Claims 1 and 2, characterized in that, the communications with each authenticated terminal device (110, 111) of the second operator being encrypted, the fifth server (160) provides the security keys necessary for said encrypted communications , and when a collection gateway (123, 124, 125; 127, 128, 129) of the first network receives (603) a message from the fifth server (160) indicating that a terminal device (110, 111) of the second operator has been successfully authenticated and including said security keys, said collection gateway (123, 124, 125; 127, 128, 129) of the first network relays (605) the security keys to the first server (131, 132, 133) associated with said collection gateway (123, 124, 125; 127, 128, 129). Method according to claim 3, characterized in that the first server (131, 132, 133) relays the security keys to the second server (134).
A method according to any one of claims 1 to 4, characterized in [Claim 6] [Claim 7] [Claim 8] [Claim 9] that, to request to join the communication system to benefit from the services of the fourth server (150 ), each terminal device (110, 111) of the second operator sends (601) a message including an identifier which uniquely identifies the fifth server (160), and in that each collection gateway (123, 124, 125; 127 , 128, 129) of the first network receiving said message determines to which address to contact the fifth server (160) by means of an association previously stored in memory between said identifier and the address for contacting the fifth server (160).
Method according to claim 5, characterized in that, on configuration of each collection gateway (123, 124, 125; 127, 128, 129) of the first network with the identifier which uniquely identifies the fifth server (160), said collection gateway (123, 124, 125; 127, 128, 129) of the first network requests a sixth server, responsible for carrying out domain name resolutions, to provide the address for contacting the fifth server (160 ) using said identifier which uniquely identifies the fifth server (160). Method according to claim 6, characterized in that, on configuration of each first server (131, 132, 133) with the identifier which uniquely identifies the fifth server (160), each first server (131, 132, 133) asks a sixth server, in charge of performing domain name resolutions, to provide the address for contacting the fifth server (160) using said identifier which uniquely identifies the fifth server (160), and each first server (131, 132, 133) propagates an association of said identifier and of said address to each collection gateway (123, 124, 125; 127, 128, 129) which is associated with said first server (131, 132, 133).
Method according to any one of Claims 1 to 7, characterized in that, when the fifth server (160) receives several copies of the same message which emanates from a terminal device (110, 111) of the second operator and which requests upon joining the communication system, the fifth server (160) performs data deduplication and responds to the first sequence copy of said message.
Method according to any one of Claims 1 to 8, characterized in that, when a collection gateway (123, 124, 125; 127, 128, 129) of the first network receives a message from the fifth server (160) indicating that a terminal device (110, 111) of the second operator has been successfully authenticated, said collection gateway (123, 124, 125; 127, 128, 129) activates a delegation (1102) and consequently notifies the first server (131 , 132, 133) with which said collection gateway (123, 124, 125; 127, 128, 129) is associated, the delegation comprising the following steps:
- assign a buffer to said terminal device (110, 111) of the second operator and store useful data therein subsequently received asynchronously via said first server (131, 132, 133) for the attention of said terminal device (110, 111) of the second operator; and
- acknowledge any ascending frame subsequently received (1201) from said terminal device (110, 111) of the second operator by constructing and transmitting (1204), on behalf of the second server (134), downlink frames including respective acknowledgments of said frames bottom-up and including, where appropriate, useful data stored in the buffer assigned to said terminal device (110, 111) of the second operator; and
- relay (1205) the ascending frame to said first server (131, 132, 133), and upon receipt (1301) of a descending frame for the attention of said terminal device (110, 111) of the second operator:
- placing (1303) the useful data, supplied in the downlink frame, in the buffer assigned to said terminal device (110, 111) of the second operator.
[Claim 10] Method according to claim 9, characterized in that each collection gateway (123, 124, 125; 127, 128, 129) of the first network which receives, coming from the first server (131, 132, 133) associated at said collection gateway (123, 124, 125; 127, 128, 129), an order to deactivate the delegation with respect to a terminal device (110, 111) of the second operator performs the following steps:
- if the buffer assigned to said terminal device (110, 111) of the second operator is empty, confirm with said first server (131, 132, 133) that said collection gateway (123, 124, 125; 127, 128, 129) has deactivated the delegation to said terminal device (110, 111) of the second operator;
- if the buffer assigned to said terminal device (110, 111) of the second operator is not empty, maintain the delegation until said buffer is emptied by construction and transmission of said descending frames by said collection gateway (123, 124, 125; 127, 128,
129). [Claim 11] Method according to claim 9, characterized in that each collection gateway (123, 124, 125; 127, 128, 129) of the first network having activated the delegation vis-à-vis a terminal device (110, 111) of the second operator increments a value of a down frame counter during the constructions of said down frames for the attention of said terminal device (110, 111) of the second operator and includes in said down frames the incremented value of the down frame counter, and when said collection gateway (123, 124, 125; 127, 128, 129) deactivates delegation, said collection gateway (123, 124, 125; 127, 128, 129) notifies (605) to the first server (131, 132 , 133) to which said collection gateway (123, 124, 125; 127, 128, 129) is associated with an up-to-date value of the downlink frame counter. [Claim 12] Method according to any one of Claims 1 to 11, characterized in that a sub-network of the first network is a communication network by carrier currents where said communication nodes are smart electric meters (170, 171, 172) and where each convergence device is a data concentrator (174, 175), and another subnet of the first network is an Internet access supply network where said communication nodes are residential gateways (180, 181 , 182) and where each convergence device is a DSLAM type multiplexer (190, 191). [Claim 13] Communication system comprising a first LPWAN type network of a first operator and a second LPWAN type network of a second operator, the first network comprising:- sub-networks (100, 101, 102) each comprising at least one convergence node (174, 175; 190, 191) and communication nodes (170, 171, 172; 180, 181, 182) integrating gateways collection (123, 124, 125; 127, 128, 129), the subnets (100, 101, 102) implementing separate respective transport protocols,- a first server (131, 132, 133), for each subnet (100, 101, 102), responsible for managing said collection gateways (123, 124, 125; 127, 128, 129) included in said sub network (100, 101, 102), each collection gateway communicating via a single convergence node associated with a single first associated server, and- a second server (134), coupled to the very first server (131, 132, 133), responsible for controlling the MAC layer for terminal devices
(110, 111) communicating via said collection gateways (123, 124, 125; 127, 128, 129) of the first network;
the second network comprising:
- a third server (140) in charge of interfacing a fourth server (150) and a fifth server (160) with the second server (134) of the first network,
- the fourth server (150), which implements an application with which at least one terminal device (110, 111) of the second operator exchanges application data within the framework of a service subscription defined with the second operator, and
- the fifth server (160), responsible for authenticating any terminal device (110, 111) seeking to join the communication system to benefit from the services of the fourth server (150);
the communication system being arranged, within the framework of a roaming management by multi-network transfer between the first network and the second network, for transporting ascending frames including application data from said at least one terminal device (110, 111) from the second operator to the fourth server (150) by successive relays of a said first server (131, 132, 133), the second server (134) and the third server (140) when said at least one terminal device (110, 111) of the second operator is authenticated and in addition that said ascending frames are received by at least one collection gateway (123, 124, 125; 127, 128, 129) of the first network, the communication system being furthermore such as each collection gateway (123, 124, 125; 127, 128, 129) of at least one subnet of the first network, which has detected a terminal device (110, 111) of the second operator asking to join the system of common ication to benefit from the services of the fourth server (150), communicate with the fifth server (160) to authenticate said terminal device (110, 111) of the detected second operator, by short-circuiting the associated first server (131, 132, 133) at said collection gateway (123, 124, 125; 127, 128, 129), the second server (134) and the third server (140) thanks to a communication interface also bypassing the convergence node (174, 175; 190, 191) associated with said collection gateway ( 123, 124, 125; 127, 128, 129).
[Claim 14] Communication system according to claim 13, characterized in that a sub-network of the first network is a communication network by carrier currents where said communication nodes are smart electric meters (170, 171, 172) and where each convergence device is a data concentrator (174, 175), and another subnet of the first network is an Internet access supply network where said communication nodes are residential gateways (180, 181 , 182) and where each convergence device is a DSLAM type multiplexer (190, 191).

类似技术:

---

公开号 | 公开日 | 专利标题

---

Seth et al.2006|Low-cost communication for rural internet kiosks using mechanical backhaul

---

US9215131B2|2015-12-15|Methods for exchanging network management messages using UDP over HTTP protocol

---

EP3629541A1|2020-04-01|Method of managing roaming by multi-network transfer

---

EP3122061B1|2018-10-03|Transmission of encrypted data from smart electric meters

---

EP3386162A1|2018-10-10|Secure end-to-end communication for mobile sensor in an iot network

---

WO2014018782A2|2014-01-30|Delay-tolerant web transaction delegations

---

CN105637819A|2016-06-01|Methods and systems for transmitting broadcast data

---

EP2853063B1|2018-10-24|Device and method for interconnecting two subnetworks

---

EP3589076A1|2020-01-01|Delegation of management of acknowledgements and transmission of frames

---

CN106604119B|2020-12-22|Network penetration method and system for private cloud equipment of smart television

---

EP3629629B1|2021-05-12|Method of managing roaming by multi-network transfer

---

EP2210396B1|2011-12-14|System of interconnection between at least one communication apparatus and at least one remote information system and interconnection method

---

EP3304832B1|2019-10-16|Method for obtaining a communication route by powerline communication

---

Jiménez Bolonio et al.2013|A distributed control plane for the Internet of Things based on a Distributed Hash Table

---

EP3777102B1|2022-02-09|Data transmission from a management entity to a smart electricity meter

---

EP3549352B1|2021-12-29|Electricity metering device comprising a powerline interface and at least a radiofrequency interface.

---

EP3709185A1|2020-09-16|Method for optimising data exchange in a connected object infrastructure

---

EP3734984B1|2021-05-26|Method for reading utility meters

---

EP3934109A1|2022-01-05|Method and device for transmitting a message

---

Date2014|Deliverable D8. 5 IoT-IPv6 integration handbook for SMEs

---

FR3077458A1|2019-08-02|METHOD OF AGGRATING A PLURALITY OF RADIO CONNECTIONS IN A WIRELESS NETWORK

---

Palattella et al.2014|Dejan D. Drajic, Srdjan Krco, Giang Nam, Rafael Marin Perez1

---

McHugh2003|Implementing TCP/IP in SCADA systems

---

Davies et al.2011|N4C System Architecture

---

Pignatari Ardila2008|Design and implementation of a distributed system to evaluate Net Neutrality

同族专利:

---

公开号 | 公开日

---

EP3629541B1|2021-06-09|

---

US20200100157A1|2020-03-26|

---

CN110944323A|2020-03-31|

---

EP3629541A1|2020-04-01|

---

FR3086482B1|2020-09-11|

---

US11223989B2|2022-01-11|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US20080129494A1|2006-12-05|2008-06-05|Electronics And Telecommunications Research Institute|Method for sensor node roaming in wireless sensor network environment|

---

US20180139274A1|2016-11-16|2018-05-17|Cisco Technology, Inc.|Application based intelligent edge computing in a low power wide area network environment|

---

CN101420762B|2007-10-23|2011-02-23|中国移动通信集团公司|Access gateway selection method, system and gateway selection execution node|

---

CN101919303B|2007-10-25|2013-11-06|思达伦特网络有限责任公司|Interworking gateway for mobile nodes|

---

JP5400222B2|2009-06-19|2014-01-29|ゼットティーイー（ユーエスエー）インコーポレーテッド|Internetworking technology that forwards packets between source and target serving gateways|

---

CN106664286B|2014-08-13|2020-09-11|宇龙计算机通信科技有限公司|Switching method and switching system between heterogeneous networks|

---

US10212577B2|2016-11-03|2019-02-19|Hewlett Packard Enterprise Development Lp|Roaming on low power wide area networks|

---

EP3603027A1|2017-03-31|2020-02-05|Convida Wireless, LLC|Interworking lpwan end nodes in mobile operator network|

---

US10726106B2|2017-05-01|2020-07-28|Centurylink Intellectual Property Llc|Internet of things devices and services for management of license reservation and granting|FR3087311B1|2018-10-16|2020-09-18|Idemia Identity & Security France|PROCESS FOR COMMUNICATING AN OBJECT WITH A NETWORK OF CONNECTED OBJECTS TO SIGNAL THAT A CLONE POTENTIALLY PASSED FOR THE OBJECT IN THE NETWORK|

---

EP3965408A1|2020-09-04|2022-03-09|Deutsche Telekom AG|Method and communication system for a power-saving operation of a subscriber line|

法律状态:
2019-08-20| PLFP| Fee payment|Year of fee payment: 2 |

---

2020-03-27| PLSC| Publication of the preliminary search report|Effective date: 20200327 |

---

2020-08-19| PLFP| Fee payment|Year of fee payment: 3 |

---

2021-08-19| PLFP| Fee payment|Year of fee payment: 4 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1871087|2018-09-25|

---

FR1871087A|FR3086482B1|2018-09-25|2018-09-25|ITINERANCE MANAGEMENT PROCESS BY MULTI-NETWORK TRANSFER|FR1871087A| FR3086482B1|2018-09-25|2018-09-25|ITINERANCE MANAGEMENT PROCESS BY MULTI-NETWORK TRANSFER|

---

US16/568,862| US11223989B2|2018-09-25|2019-09-12|Method for managing handover roaming|

---

EP19198058.0A| EP3629541B1|2018-09-25|2019-09-18|Method of managing roaming by multi-network transfer|

---

CN201910912851.6A| CN110944323A|2018-09-25|2019-09-25|Method for managing handover roaming|